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ABSTRACT 


Smart cards play an important role in a digital society. A smart card contains 
memory or an embedded microprocessor with the capability of enabling a wide variety 
of services, such as electronic cash in the case of memory cards and digital signature 
computation in the case of processor cards. A processor card can require a cardholder 
to authenticate herself in order to prevent others from using the card’s services, from 
forging the cardholder’s signature, for example. Authentication can be done by storing 
a personal identification number (PIN) or digitized fingerprint of the cardholder on 
the card itself. The PIN or fingerprint must always remain confidential no matter 
how the card is (ab)used. 

This thesis addresses the problem of preserving the privacy of information 
stored on smart cards. Volpano and Smith have developed a static analysis for ana- 
lyzing source code for information flow violations. This technique is developed further 
here for a language called Java Card, in which smart card applications are written. | 
A prototype analyzer is presented for a subset of Java Card and applied to a sample 
card application to demonstrate its utility in protecting private information stored 


on smart cards. 
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I. INTRODUCTION 


Magnetic-stripe cards with an embedded microprocessor have been around for 
many years. They are typically called smart cards and come in two varieties: memory 
cards and processor cards. A processor card has roughly the computing equivalent of — 
a vintage 1980 personal computer with an 8-bit microprocessor, 512 bytes of RAM 
and 16K bytes of ROM. It can run applications and make decisions, unlike plain 
magnetic-stripe cards. 

The first smart cards in wide-spread use were simple “memory”, or stored- 
value, cards that served as electronic “purses” for small purchases. French banks were 
the first to introduce these cards, and the European telephone companies used them 
in place of coins in public telephones. Some stored-value cards cannot be recharged 
and are discarded after they are depleted. Others can be replenished with cash value 
at ATM-like stations. Fast-food giant McDonalds (tm) of Germany, for instance, 
allows customers to purchase food with rechargeable, stored-value cards. And if 
your card needs to be recharged, McDonalds provides automated tellers within its 
restaurants for this purpose. Smart cards have also been adopted for use in Europe’s 
Global System of Mobile Communications (GSM). GSM cell-phone manufacturers 
have decided to equip handsets with smart-card readers. Users store their identity 
on smart cards and are able to use any such equipped cell phone. This is in contrast 
to having phones with their own identities, say a transmission frequency fingerprint, 
which, if intercepted, can lead to cell-phone cloning. 

Smart cards obviously must store private information to be useful. For in- 
stance, a smart card user typically authenticates herself using a personal identifica- 
tion number (PIN) entered by a keypad attached to a card reader. The number is 
compared with a PIN stored on the card by code that is part of the card’s operating 
system. This code and any other application running on the card that can inspect 


the stored PIN may (covertly) leak the PIN without knowing it. This occurs through 





what are called covert channels, and there are many different kinds of such chan- 
nels. Volpano and Smith address limiting the bandwidth of these channels through 
statically analyzing the source code of smart-card applications. This thesis explores 
extending their work to Java Card, a particular programming language embraced by 


some smart-card vendors for writing portable smart-card applications. 


A. THE ARCHITECTURE OF A SMART CARD 
Smart cards come in two basic flavors, memory and processor cards. They are 
the size of conventional magnetic stripe cards, but each carries a chip, which makes it 
smarter and more valuable. A card’s architecture is given in terms of its hardware and 
software. On. the software side, there is the runtime environment afforded applications 
_ running on the card. Hardware characteristics across cards tend to vary far less 
than do the runtime environments. Below are some examples of different hardware 
configurations. 
1. Integrated. Circuit(IC) Microprocessor Card: a card with 8-bit processor, 16 
KB read-only memory (ROM),and 512 bytes of random access memory (RAM) 
2. Integrated Circuit(IC) Memory Card: a card with 1-4 KB of data storage 


3. Optical Memory Card: a card combined with a Compact Disk that can hold 
4 MB of data 


Smart cards also vary according to their operating, or runtime, environments. 
A runtime environment provides an interface between the card and the card termi- 
nal known as the card acceptance device (CAD). A CAD inputs requests from a 
card holder and is the card’s interface to the outside world. Runtime environments 
typically vary across smart card vendors. Examples include the following. 
1. PS/SC is one of the proprietary runtime environments supported by Microsoft. 
This environment currently supports only the Win32-based platforms. 


2. OpenCard Framework is an other specification for the runtime environment. 
It is an open standard designed to provide interoperability of smart card ap- 
plications across network computers, desktops, laptops, set tops, and so on. 











3. JavaCard is another runtime environment. It was introduced by Schlumberger 
and submitted as a standard by JavaSoft. JavaCard is a set of standard classes, 
which is a subset of standard Java. JavaCard is designed to develop secure 
and hardware-independent applications. These applications consist of Applets 
that are quite similar to the Applets that run within a web browser. 

Smart cards have the potential for a wide range of applications. For example, 
today we use different cards for different purposes, such as shopping and on-line 
transactions. A smart card can integrate these different areas and serve as a bridge © 
between consumer electronic devices and the card holder. It might seem that such a 
tiny card would not have much functionality, but the point is not what the card does, 
but rather the kinds of services it enables. The idea is not to run big applications, 


but to provide access to them. We call these applications services. Other examples 


of the services enabled by smart cards include: 


e Cable TV authentication 

e Storage Internet addresses as bookmarks 

e USPS certified e-mail 

e Subscriptions to several advanced news services 

e Subscriptions to some pay-per-view video streaming channels 


e Ticketing 


A smart card can provide a single interface to many services; however, there 
are security risks. Quite often a smart card must handle personal information in 
order to enable the services listed above. Depending on the service, some of this 
information may be stored on the card. It is important that the privacy and integrity 
of such information be preserved. As a simple example, suppose a program running 
on a smart card has the property that it throws a particular kind of exception if 
and only if some private bit is on (By the way, this property may be unkown to the 
programmer.). If the exception is not caught and handled, it will reach the card’s 
interface and will be observable by any card user. So its presence, or absence, reveals 


the private bit. 








B. SCOPE OF THESIS 

This thesis explores an approach to enforcing privacy in software using a type 
system, an idea originating with Volpano and Smith [Ref. 1]. It is concerned with 
adapting an earlier type system of theirs to Java Card 2.0, an object-oriented language 
for smart card applications. Java Card is interesting because applications (Applets) 
can run on any card with the Java Card Runtime Environment (JCRE) installed. 
This is a much more open framework. The new type system requires changes to their 
original type inference algorithm. This thesis addresses these changes. Obviously, 
there are other security issues for smart cards, such as the integrity of information 
stored on the card. This thesis focuses on privacy only. In an earlier thesis, Harvey 
[Ref. 2] adapted the type system of Volpano and Smith to address some features 
of Java Card 2.0. However, his thesis does not treat objects nor consider function — 
methods. 

We begin by exploring Java Card 2.0 and the Java Card Virtual Machine 
speci heations Then, in Chapter ITI, we give the core language for which the type 
system is developed. It is close to full Java Card 2.0. The type system for enforcing 
privacy is also given. In Chapter IV, we give a type inane algorithm for deciding 
whether programs have types in the system of Chapter Ill. It is called the secure flow 
analyzer. An application of the secure flow analyzer is given on a small Applet in 


Chapter V. 














Il. JAVA CARD AND THE VIRTUAL 
MACHINE 


The widespread use of smart cards has been hampered by the traditional 
practice of smart card vendors. Each would embed its card’s operations in its own 
proprietary operating system (OS), making it difficult to extend a card’s functionality 
or to port that functionality to another card. There was a need to separate the card’s 
OS from its applications and to develop those applications in a way that would allow 
them to be portable across a wide variety of smart cards. Recognizing this need, 
Visa International teamed up with Integrity Arts to design an open platform for 
smart cards in 1995. Simultaneously, the French smart-card maker Schlumberger was 
developing an architecture for the same purpose. The Schlumberger architecture re- 
sembled Sun’s Java platform, which was being released as JDK 1.0 at the time. There 
was enough of a similarity that Visa and Schlumberger convinced Sun Microsystems 
to develop a specification of the smart card open platform. Java Card was born. The 
Java Card 1.0 specification was released in October 1996, and version 2.0 was released 
a year later. Version 2.1 is expected to be publicly available by October 1998. | 

Though based on Java, Java Card 2.0 differs from Java in many ways. The 
Java Card 2.0 language is used basically to program smart cards that implement the 
Java Card Runtime Environment (JCRE). The language and runtime environment 
are based on the Java programming language and the Java Virtual Machine (J VM). 
Java Card and the JCRE are described in [Ref. 3]. The most important ways that 
Java Card differs from Java are highlighted below: 


1. Dynamic class loading: A Java Card System is not capable of loading classes 
dynamically. The transfer of the class files is done statically either during or 
after production of the card. 


2. Security Manager: The security model of Java Card is considerably different 
from standard Java. There is no customizable security manager. Security 
policies are encoded in the virtual machine. 








3. Threads: There is only one thread of control in a Java Card System. Neither 
Thread class in Java nor any structure about threads can be used in Java 
Card. 





4. Cloning: Objects in a Java Card system are not cloneable. The base Object 
class does not implement the clone() method, and there is also no Cloneable 
interface. 


5. Garbage Collection and Finalization: Java Card does not require garbage 
collection. It also does not allow explicit deallocation of the objects as Java 
does. Finalization also is not required. The virtual machine will not call a 
finalize method automatically. 


A. CARD PROGRAMMING CONCEPTS 


Programming in Java Card is quite different from other applications. The 
following list of concepts is important in understanding a Java Card application [Ref. 
4]. Some of the concepts come from a smart card standard promulgated by the 
International Standards Organization (ISO). In particular, they are part of the ISO 
7816 standard. . 


1. Applications have unique identifiers as defined in ISO 7816-5. Each is called 
an AID, which stands for Application Identifier. 


2. The card interfaces with the outside world via a data structure called the 
Application Protocol Data Unit, or APDU. It is described in ISO 7816-5. 


3. The basic unit of execution on a Java Card is the Applet. It is the entry point 
for a service provided by the card. 


4. Applet Execution Context. The JCRE keeps track of the currently selected 
Applet as well as the currently active Applet. The environment of the currently 
active Applet is referred to as the Applet Execution Context. When a virtual 
method is invoked on an object, the Applet execution ‘context is changed to 
correspond to the Applet that owns that object. When the method returns, the 
previous context is restored. Invocations of the static methods have no effect 
on the Applet execution context. The Applet execution context and sharing 
status of an object together determine if access to that object is permitted. 


9. Card Acceptance Device. A Java Card, like any smart card, gets inserted into 
a card terminal for its power supply and interface. This terminal is often called 
the Card Acceptance Device, or CAD. 








6. Atomic Operation. This is an operation that can never be partially executed. 
Either it executes to completion or does not execute at all. The property is 
needed in order to guarantee invariant conditions in the presence of unexpected 
behavior, such as loss of power to the card after being removed from the CAD. 


7. Transaction. A transaction is an atomic operation where the programmer 
defines the extent of the operation by indicating in the program code the 
beginning and end of the transaction. 


8 Java Card Runtime Environment. This environment consists of the Java Card- 
Virtual Machine and the core classes in the Java Card API. 


9. Persistent Object. A persistent object is one whose state persists between card 
insertions. Objects are persistent by default. Persistent-object state is updated 
atomically using transactions. The term persistent does not mean there is an. 
object-oriented database on the card or that objects are serialized /deserialized, 
just that the objects are not lost when the card loses power. 


10. Transient Object. A transient object is one whose state is not saved across 
card insertions. Its state is reset to a default state at specified intervals. 
Updates to the state of transient objects are not atomic and are not affected 
by transactions. 


B. THE JAVA CARD FRAMEWORK 

ISO 7816 or EMV (Europay, MasterCard, Visa) is the underlying standard on 
which Java Card 2.0 stands. ISO 7816 defines the standards for Integrated Circuit 
Cards (ICCs) with contacts, also known as smart cards. It covers the various aspects 
of the Smart Cards, and consists of six parts. The Java Card framework is designed 
to handle most of the low-level details specified in ISO 7816, parts 1-3. It also 
provides classes and methods that assist developers in being compatible with parts 4- 
6. The EMV standard, which is defined by the members of the international financial 
community, consists of a subset of ISO 7816 Part 1-6, with additional proprietary 


features which are required to meet the specific needs of the financial industry. 


1. Applets | 
Applets in Java Card correspond to the application in ISO 7816. They are 


the basic unit of selection, context, functionality, and security [Ref. 4]. They are 








identified by an Application Identifier (AID) and selected by a CAD on demand. A 
CAD sends formatted commands as APDU buffers to Applets. Applets reply to each 
APDU command with optional data and indicate the results of the operation using 
a status word (SW) as defined in ISO 7816 Part-4. Applets define the behavior of an 
object when they are instantiated. They are a subclass of javacard.system. Applet, 
which defines the common behavior of all Applets. A package is a collection of Applets 


as in Java. 


2. Objects 

Objects in Java Card have the same behavior as in Java. They are used to 
represent, store, and manipulate data by the Applets. An Applet which instantiates 
the object is able to use and modify the object. Objects created by an Applet can be 
shared with other Applets as long as the owner of the Applet permits sharing. The 


rules defining the lifetime of an object and its creation are as follows: 


e The lifetime of an object depends on the existence of a pointer pointing to it. 
The pointer can be stored in a local or parameter variable or field of another 
object. 


e Once an object is instantiated, all the fields of the object are set to their 
default values. For example, if the data type of a field is int, then its default 
value will be 0 as in Java. 


An object is persistent if 1) the object is the subclass of the Applet class 
and registers itself, 2) the JCRE stores the reference to these objects to make them 
persistent, or 3) the object is a part of another persistent object. If the object is 
not registered or not referenced by any other persistent object, it can be discarded or 


garbage collected. 


3. Virtual Machine 
In a PC or workstation, the Java Virtual Machine is a regular process. When 
the process dies, the resources of the object are deallocated. But the execution lifetime 


of the Java Card Virtual Machine is the lifetime of the card. The virtual machine does 














not depend on any other power source and uses persistent memory technology (such 
as EEPROM). During the card initialization stage, the framework and the JORE 
are installed and exist for the lifetime of the virtual machine[Ref. 4]. The execution 
lifetime of the JCRE and the framework span CAD sessions. Therefore, the execution 
lifetime of the objects created by the Applets of the framework spans CAD sessions 


as long as there is a reference to them. 


4. Transactions 
Transactions are among the most important concepts in Java Card. The 
: atomic transaction model of Java Card requires that the updates to the fields of 
an object take place correctly and consistently or else all fields are restored to their 
previous values. An Applet has the ability to mark the beginning and end of an 
atomic transaction. It also has the ability to undo all updates in the middle of a 
transaction if it encounters an internal problem or decides to cancel the transaction. 

The current transaction model allows one transaction in progress at a time. 
If an attempt is made to enter a transaction within another transaction, then an 
exception is thrown. Java Card allows Applets to inspect whether a transaction is still 
in progress. If power should fail while a transaction is in progress, all fields updated 
since the start of the transaction are restored to their previous values. ‘The restoration 
is done during re-initialization after the failure or reset by the JCRE. Transient objects 
are not restored upon re-initialization following an aborted transaction. In the case of 
an internal problem, an Applet can decide to abort the transaction by a method call. 
All the values updated since the beginning of the transaction are restored to their 
previous values, and the transaction flag is reset. If a select, deselect or process 
method is invoked while in a transaction, the JCRE will automatically abort the 
transaction. 

Finally, the resources of a Java Card system are limited. The number of 
bytes of conditionally updated objects that can be accumulated during a transaction 


cannot exceed this limit. Java Card provides functions to query how much commit 





capacity is available on the current platform. Exceeding the commit capacity causes 
an exception. The JORE can choose to either mute the exception or make it visible 


to the interface. 


5. Applet Isolation and Object Sharing 

Applet isolation is provided by an Applet firewall which prevents one Applet 
from accessing objects owned by other Applets. The Applet that was active when the 
object was created owns the object. All the privileges to use and to modify the object 
belong to the owner. An Applet can have a reference to the object which is created 
by another Applet but it cannot invoke methods on the object or set the contents of 
its fields. On the other hand, the JCRE must be able to invoke methods on Applets, 
and Applets must be able to use objects owned by the JCRE. If an Applet does not 
have sharing privileges for an object, any attempt to invoke an instance method or 
access the objects’s contents will throw a Security Exception. 

The JCRE can modify any object on the card whether or not that object is 
shared. An Applet may permit unrestricted sharing of any of its objects. Once the 
object is shared, it is shared for its remaining lifetime. An Applet may also permit 
restricted sharing of any of its objects. Restricted sharing can be used when one wants 
to share an object with a certain Applet. An Applet can call the share method more 


than once to share the object with different Applets. 


6. Applet Lifetime and Runtime Environment 

An Applet lives as long as the card since it is loaded onto the card during card 
production. Applets are a subclass of the Applet class, as mentioned above. The 
JCRE interacts with the Applet via the Applet’s public methods install, select, 
deselect, and process. The Applet must implement the install method. If the 
install method is not implemented, the Applet’s objects cannot be created or ini- 
tialized [Ref. 4]. 


After installation (calling the install method), an Applet is responsible for 
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its own state, which it determines by the way it responds to the invocation of its 
select, deselect, and process methods. Basically, Applets are completely respon- 
sible for their internal state. The mechanics of the Applet invocation are as follows. 
Any select APDU with-the Applet’s AID will cause this Applet’s select method to 
be invoked. Any select APDU with another Applet’s AID will cause this Applet’s 
deselect method to be invoked. Any APDU other an select will cause this Ap- 
plet’s process method to be invoked. Once an Applet is selected, it stays selected until 
power is lost, the card is reset, or another Applet is selected. When the Applet is 
selected, its process method can maintain its own state (including states like blocked 
or expired), reference (read and write) its own objects, reference shared objects, share 
its objects with other Applets, enclose multiple updates in a transaction, create new 
objects (if the policy allows this), and invoke services provided by the Java Card 
Application Programming Interface, such as Personal Identification Number (PIN), 
cryptography, and file system services. 

Power loss occurs when the card is withdrawn from the CAD. When power is * 
re-supplied to the card , the JCRE ensures that all transient object fields are reset 
to their default. state, the transaction in progress, if any, is aborted, and the Applet 


becomes deselected but the deselect method is not called. 


7. The APDU 

A Smart Card uses data units to communicate with the outside world. These 
units, called APDU buffers, contain either a command or a response message. A 
smart card system follows the master-slave model in which the smart card plays the 
passive role. In other words, a smart card always waits for a command APDU from 
a terminal. It then executes the action specified in the APDU and replies to the 
terminal with a response APDU. The command APDU has the format in Figure 1. 


The header contains the coding of a command. It has four fields: 


1. CLA Class byte. In many Smart Cards, this byte is used to identify an appli- 
cation. 
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_ Command APDU 
Mandotary Header Conditional Body 
Data Field 


Figure 1. Command APDU Format 






2. INS Instruction byte. This byte indicates the instruction code. 


3. P1-P2 Parameter bytes. These provide further qualification of the APDU 
command. 


The conditional body has two fields other than the data field: 


1. Lc denotes the number of bytes in the data field of the command APDU. 


2. Le denotes the maximum number of bytes expected in the data field of the 
response APDU. 


The response APDU has the format in Figure 2. 


erent TTT TOTO 


Response APDU 


Conditional Body | Mandatory Trailer 
Data Field 


Figure 2. Response APDU Format 







The status bytes SW1 and SW2 denote the processing status of the command 
APDU in a card. The Java Card APDU class provides methods to handle APDUs 
which conform to the ISO 7816 Part-4. It is also carefully designed to abstract the 
underlying transport protocol changes. We can summarize the responses of Java Card 
to the different APDU commands as follows. In the first case, there are no command 
data and no response data. In the second case, there are no command data, but there 


are response data. The details of these cases can be found in [Ref. 4]. 
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ITI. THE LANGUAGE AND TYPE SYSTEM 


The secure flow type system covers a subset of Java Card 2.0. The major 
structures of the language are treated, however, some features have been omitted. For 
example, transactions have not been considered. Although committing a transaction 
is done through a method call, the implications of it, from a privacy standpoint, need 


to be investigated. 


A. THE LANGUAGE 


In the following grammar, e denotes an expression, c a command, and 6 a 


function body. We use z,y,... to denote identifiers and n to stand for an arbitrary 


integer. 
p == .€:| Cc 
eu= n|az |e, + e2 | x(e,e’) | ze] | new int/e| 
ba ee | e1 = € | intz := e; eé! | 
int|]z := e; e’ | ife then e; else ey 
C m= e€; := e€2 | ifethencelsec’ | 
Cx :=newC(e,e’);c | intz = ec | cc | 


int] ] xz := e; c | int z(int z, intl] y){b} c | 
void z(int x, int[] y){c}c | x(e,e’) 


Notice that the body 6 of a function 
int z(int x, int[{] y){b} 


is not a command. This means that no procedure call is allowed in a function body. 
A function body is an extension of the expressions that allows some commands to 
be used and typed as expressions. Consequently, special consideration is needed in 
typing function method declarations, as we shall see, in order to preserve an important 


security property of well-typed programs called Confinement. 
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An array declaration 
int|]|z := e; c 
declares an array reference variable x and initializes it to the reference value obtained 


by evaluating expression e. The expression e has the form 
new int/e’] 


for some expression e’. Array references are first-class values, whereas variables are 


not. The declaration 
Cz := new C(e,e’); c 


declares a reference x to a C object. The language differs from Java Card 2.0 in that 
the right side of the declaration is not an expression. We couple object creation with 
variable declaration. Objects cannot be created by executing an expression. They 
can be created only in the context of an object variable declaration. Further, we allow 
at most one object to be created for a given class. This means that methods are not 


_ polymorphic like procedures in [Ref. 1]. 


B. TYPING RULES 


The types of the secure flow type system are given below: 


ee De 
x := T | 7 proc(t,r arr) | 7 fun(r,7 arr) .| rt arr fun(r,7 arr) 
p s:= nm | tT var | Tarr | 7 arr var | tT cmd 


Every integer has a type 7 which for our purposes is a security level high (H) or 
low (ZL). A constant array reference has type 7 arr and is a single-dimensional array. 
Functions return either an integer or an array reference and have types 7 fun and 
T arr fun respectively. Variables have type 7 var and a variable that stores an array 
reference has type 7 arr var. (Notice that we distinguish.an array reference from an 


array reference variable. ) 
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(IDENT) a ae eee op Ba 
(VAR) yl a:T var y(x) = 7 var 
(ARRREF) NAG OTT Ve) 7 arr 
(ARRREFVAR) yl a:tarrvar (x) =7 arr var 
(INT) Sa me a 
(R-VAL) yke:7T var 

vest 


yke:T arr var 
yre:T arr 


(SUM) yke:7T, yRKe:t 
yrKe+te:T 
(NEW) yhee:T 
| vy new intle|: 7 arr 
(RETURN) err 
vy return €: 7 
(ARR-INDEX) PEGI. Ve Se 
yt ale]: 7 var 
(COMPOSE) Veet, Vere oT 
ylee;e:T 
(ASSIGN) yhke:rvar, yre:T 
ykereit 
(LETVAR) yke:7T, yle:7 var] e': 7’ 


9wrint t=e7¢6e 17 


(LETARRVARIL) yke:rarr, y[x:7 arr var]Fe':7' 
yk int{|2s=e;e:7 
(FUNCALL) v(x) = 7 fun(r,7 arr) 
ress. 
ylke:7 arr 
yk x(e,e'):7 
UF) yre:t, yhein yrelin 
yt if e then e’ else e" : T 


Figure 3. Typing Rules for Expressions 
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(RETURN) yt return: 7 cmd 
(COMPOSE) yresr ema, Vre <7 emd 


res 6 or cmd 


(ASSIGN) yrke:rarrvar, yk e’: tau arr 
ykKe:=e':r cmd 


(LETVAR) y-e:7, [2:7 var] c:7' cmd 
vant £62 C27 cma 


(LETARRVAR2) yhre:7rarr, ylx:7 arr var) c:7' cmd 
yt int|] z:=e;c¢:7' cmd 


(LETFUN) ye:t'sy:7' arr] b: 7 
bis pure with respect to y[y: 7’ arr] 
Veo june .7 am)) es 7 ema 


(LETPROC) yle:c',y:c" arr) Ee: 7” emd 
ylz:7” proc(r',7” arr)| ke: 7 cmd 
y' void z(int xz, int|| y) {c} c: 7 cmd 


(PROCCALL) y(z) = 7 proc(t',7” arr) 
yee: : 
yk e':7” arr 
yt x(e,e’): 7 emd 
(IF) ye: T, yrke:remd, yKed:7 emd, 
yk if e then c else c’: 7 cmd 


(WHILE) yke:T, yke:7T cmd 
-yE while e do c:7 cmd_ 
(LETOBJECT) = _(C) = 7 proc(7’,7” arr) 
yr eer 
yk-e': 7" arr 
yr-oe:T cmd 
“yEC a := new C (e, e');¢:7T cmd 


Figure 4. Typing Rules for Commands 
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The typing rules are given in Figures 3 and 4. Notice how array indexing is 
typed in rule ARR-INDEX. The security level of the index and the array reference 
must be the same. That means that arrays can store only information whose security 
level is equal to the array reference. 

Array declarations have two different rules, one (LETARRVAR1) for expres- 
sion contexts and the other (LETARRVAR2) for command contexts. These rules 
introduce array references as first-class values. Function declaration has an unusual 
typing rule. We require body 6 to be pure with respect to y, which means that for 
all y € dom(7), y is not updated in 6 if y is free in 6 and either y(y) = L var or 
y(y) = L arr. In other words, all assignments in a function body involve assignments 


to local variables only unless their security levels are high. 


C. CONFINEMENT 

Java Card 2.0 inherits the assignment expression, pre/post increment /decre- 
ment and conditional expressions from Java. These structures cause side effects in an 
expression, which can violate an important property called Confinement if they are | 
not typed appropriately. Basically, Confinement says that the execution of any high 
command does not result in updating any low variables. For example, suppose that 


zx is a high boolean variable and y is a low boolean variable, and consider 
if xthenz := (y := 1) 


If the expression (y := 1) can be typed as a high expression and the command 
x := (y := 1) can be typed as a high command, then the whole conditional can be 
typed as a high command. But y is a low variable and the execution of the conditional 
causes a low variable to be updated, which is a violation of Confinement. ‘To preserve 
Confinement, the type system demands that function bodies be pure. Other Java 
Card expressions like pre/post increment/decrement could easily be added to the 
language without affecting the type system as long as they are limited to function 


bodies where the typing rule for function declarations comes into play. 


Lf 
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IV. THE SECURE FLOW TYPE 
INFERENCE ALGORITHM 


The secure flow type inference algorithm is based on the algorithm of Volpano 
and Smith given in [Ref. 1]. It is given for the language and the type system described 
in Chapter III. 


A. THE TYPE INFERENCE ALGORITHM 
The type inference algorithm W has the following inputs and outputs: 


e Inputs 


i 4: a type environment — maintains types of free identifiers and variables. 
Zep 
3. V: aset of stale type variables — empty initially. 


: a program phrase — the phrase to be typed. 


e Outputs | 


1. C : a constraint set — consists of inequalities of the form 7 < 7’. A 
constraint 7 = 7’ is understood to mean 7 < 7’ and 7’ <T. 


2. % : am type with type variables — the result type of the phrase p. 


3. V': a set of stale type variables — (V’ — V) is the set of type variables 
generated during the typing of phrase p. 


The algorithm is given by cases in Figures 5, 6 and 7. Each case corresponds 
to a different phrase of the language. | 

Notice that the rule for an expression z[e] requires that the security level of the 
index and the array reference be the same. Naturally, we add a constraint that forces 
them to be equal, specifically F = 7,. Also notice the coercions in several places in the 
algorithm. They have the form 7 < a or a <7 for some fresh type variable a. The 
first is an upward coercion reflecting the idea that a low producer (expression) may 
be regarded as a high producer. The second is a downward coercion and effectively 


reflects the idea that a high consumer (command) can be a low consumer. Algorithm 
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W (4, p, V) = case p of 


x: case ¥(x) of 
7: ({7<a},a,VU{as) a€dV 
Tvar: ({F<a},a,VU{a}) a¢gV 
Farr: ({ },F arr, VU }) 
Farr var: ({},7 arr,VU{}) © 
default : fail 


n:({},a,VU{a}) a€gV 

€, + €2: 
let (C1,71, V’) = WO,7, e1, V) 
let (C2, 72,V") = W(,,4, €2, V’) 
in (C; U Cr U {Fy = 72}, 75 v") 


zie]: 
let (C",71,V’) = W(4, e, V) 
case ¥(x) of 
T arr var: (CU{7=7,7 <asa,VU{a}) agV 
Farr: (C/U{F=7,7 <asa,VU{a}) agV 
default : fail 
€, :=— €2: 


case e, of 
x: if ¥(x) =7 var then 
let (C, 7’, V') = W(4, €2, V) in 
(CU{T=7,a<7},acmd,V'Uf{a}) agV' 
elsif ¥(x) = 7 arr var then 
let (C,7" arr, V’) = W(%, e2, V) in 
(CU{T=7,a<7},acmd,V'Uf{at) a¢gV! 
else fail | 
zie]: if ¥(x) =7 arr var or ¥(z) =F arr then 
let (C,7",V") = W(F, €9,V) in 
(CU{T=7,a<7},acmd,V'Uf{al) agV’ 
else fail 
default : fail 


new nativele] : 
let native ::= short | boolean | byte 
let(C,7,V’) =W(4, e, V) in (C,F arr, V") 


Figure 5. Algorithm W 
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if e then c; else c : 
let (C,7,V') = W(4, e, V) 
let (Cy, 7, cmd, V") = W(7, 41, VV) 
let (Co, 7 cmd, V") = W(F, 2, V") 
in (CUC|UQ,U{F# =7 =h,a <Th,acmd,V"U{a}) agV™ 


while e doc: 
let (C,7, V’) = W(4,e,V) 
let (C",7 -! cmd, V") = W(4,c, V’) 
in (CUC ULF =F, a<Fh,a cmd, V"U {a}) ae" 


C1; Co: 
let (C1, 7 cmd, V’) = W(F, a, V) 
let (Co, T cmd, y") = Wy, C2, V’) 
in (Cy UC2U {F, = 72h, 7, emd,V") 


int ¢¢=e 3c: 
let (C,7,V’) = W(4,¢,V) 
let (C’,7’ cmd, V”) = W(A[x : 7 var], c, V’) 
in (CUC’,7’ cmd, V") 


int z:=e;e': 
let (C,7,V") = W(,74, 4, V) 
let (C’,7’,V") =W(A, al 7 var|,e’, V") 
in (CUC' FV" 


int[] c:=e;c: 
let (C,7 arr, V’) =W(),,7,e, V) 
let (C’,7 cmd, V"”) = W(,,4 [x : 7 arr var], c, V’) 
in (CUC",7"' cmd,V") 


int|] z:=e;e': 
let (C,7 arr, V’) = WO0,,7,e, V) | 
let (C'",77,V") =W(, Aa : 7 arr var], e’, V’) 
in (C U-C"",7',V") 


int z(int z, int|] y) {b} c: 
let (C,7,V') =W(,, 49x: 7,y:7 arrl,b,V) 
let (C",7 et cmd, V") = W(A Ale: 7 fun(7,7 arr)],c,V") 
in (CUC',7' cmd, V") 


Figure 6. Algorithm W, continued 
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void z(int x, int] y) {c} c: 
let (C,7" cmd, V') =WO,9 2: 7,y: 7 arrl,c, V) 
let (C’, 7” cmd, V") = W(A,4|z : 7" proc(7, 7’ arr)],c, V') 
in (CUC""»,7"" cmd, V") 


Cz := new C (e, e’) 5c: 
if ¥(C) = 7" proc(?,7" arr) 
let (C, Ti, Ve) — WO, 7, €, V) 
let (C", 7 arr, V") = W(,¥4, e, V’) 
let (C", 7" emd,V") = W(),7’,¢, V") 
—miCcuCc wc UT =—F,7 =p end,.V") 
else fail 
r(e,e’): . 
if F(a) = 7" proc(T,7 arr) 
et (C, 7, V’) = WA, ey, €, V) 
let (C’, 7 arr, V") = W(,47, e, V’) 
in (CUC'UC"U{# =%,7 =}, 7" cmd, V") 
elsif ¥(x) = 7 fun(T,7 arr) 
let (C,7, V’) =W(,7,e,V) 
let (C’, 72 arr, V"”) = W(A,4, e', V’) 
in (CUC'UC" U{F#=%,F% =f},7,V" 
else fail 


Figure 7. Algorithm W, continued 


W on a function method call, where the function returns an array reference, is defined 
like it is for functions returning integers. The return type becomes 7 arr. Therefore, 


this case is omitted from the specification of W in Figure 7. 


B. AN IMPLEMENTATION IN JAVACC 

The type inference algorithm has been implemented using a compiler-compiler 
called JavaCC. JavaCC generates a top-down parser for a given syntactic/semantic 
specification as input. For us, the semantic component is the secure flow type inference 
algorithm. The generated parser implements the algorithm above. Starting with a 
JavaCC specification for Java 1.0.2, a specification was built for the core language of 


Chapter III. We needed to make many changes in the specification since the language 
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in Chapter III is a significant subset of Java 1.0.2. The result was a secure-flow 
analyzer for most of Java Card 2.0. In Chapter V, we analyze a sample Card Applet 


using the analyzer. 
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V. APPLICATION OF THE SECURE FLOW 
ANALYZER 


Now we shall take a look at a sample Java Card Applet using the Java Card 
2.0 API and our secure flow analyzer in order to determine whether or not fie Applet 
leaks any information about a private crypto key. We have the following scenario. A 
smart card comes with a preloaded decryption library and a crypto key. The sample 
Applet’s task is to receive encrypted data from the CAD and then submit it to a 
decryption method in a library. The decryption method will use the key to decrypt 
the data. To differentiate the tasks, we will refer to the sample Applet as the Client 
Applet and the decryption library as the Decrypt class. 


A. THE CLIENT APPLET 
The Client Applet is given in Figure 8. It uses a variety of different methods 


from the Java Card 2.0 API: 


e install( 


1. Create the Applet’s instance. 
2. Register the Applet (by calling the constructor). 


e select() 


1. Select the Applet. 


2. Return true to guarantee selection in this case. 


e process () 


1. Check that the correct commands are received from the CAD. 


2. Send the encrypted data to the library. 
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import javacard.framework. *; 


public class Client extends Applet { 


public static final byte CLIENT_CLA = (byte) 0x80; 
public static final byte CLIENT_INS = (byte) 0x20; 


private byte[] buffer; 
private decrypt; 


public Client() { 


decrypt = Decrypt.getDecrypt() ; 
register () ; 


} 
public boolean select() { return true; } 
public static void install(APDU apdu) throws ISOException f{ 


new Client(); 


} 
public void process(APDU apdu) throws ISOException { 
buffer = apdu.getBuffer() ; 
if ( CLIENT_CLA != buffer[ISO.OFFSET_CLA] ) 
ISOException.throwIt (ISO.SW_CLA_NOT_SUPPORTED) ; 
if ( CLIENT_INS != buffer({ISO.OFFSET_INS] ) 
ISOException.throwIt (ISO.SW_INS_NOT_SUPPORTED) ; 
apdu.setIncomingAndReceive() ; 
decrypt .decrypt (buffer) ; 


} 
} 


Figure 8. Client.java 
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The Decrypt class is given in Figure 9. Its methods are described below. 


e getDecrypt () 


1. Return the single instance of the Decrypt class. 


e decrypt () 


1. Check whether key is set or not. 
2. Check whether the input data buffer size is bigger than the expected size. 


3. Decrypt the data. 


import javacard.framework.*; 
public class Decrypt { 


private static final short KEY_NOT_SET = OxFFO1; 
private static byte[] buffer = new byte[50]; 


private Decrypt() {} 
private static final Decrypt decrypt = new Decrypt(); 
public static Decrypt getDecrypt() { return decrypt; } 


public void decrypt(byteL[] data) f 


if (key == 0) f{ 
ISOException.throwIt (KEY_NOT_SET) ; 

+ else { | 
if (data[ISO.OFFSET_LC] > buffer.length) 

ISOException.throwIt (ISO.SW_WRONG_LENGTH) ; 

// Start decryption - End decryption 

} 

} 
t 


Figure 9. Decrypt.java 
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B. THE TYPE ENVIRONMENT FOR THE API 
In order to use the analyzer, we need to build an initial type environment that 


gives the types of methods and identifiers occuring free in the Applet: 


1. apdu.setIncomingAndReceive(): L proc()- this is the primary receive met- 
hod[Ref. 5]. It returns the number of bytes that can fit in the APDU buffer 
and also transfers the bytes from the CAD to the APDU buffer. Since we 
assume all data from the CAD is low, this method is typed low. Also, this 
method cannot be typed as a function, as in Java Card 2.0, since it has side 
effects. 


2. apdu.setOutgoingAndSend(): L proc(L,L)— this is the send method. It sends 
lien bytes in the APDU buffer, starting from off, to the CAD. Since the CAD. 
is low, the method is low. The parameters of the method are also low, since 
they can be observed in the response APDU. 


3. apdu.getBuffer(): L arr func()—- this method returns a byte array containing 
the APDU buffer. We always regard this buffer as low since it can be seen at 
the CAD. 


4. ISOException.throwIt(sw): L proc(L)— throws the JCRE instance of the 
ISOException class with the specified status word sw. The parameter is typed 
low since the status word can appear as swi and sw2 of a response APDU. 


5. key: H- a private crypto key. — 


6. register(): H proc()- this method is final and inherited from Applet class. 
It registers an Applet with the JCRE and appears not to involve any updates 
of low data structures. Although this needs to be confirmed, we shall go ahead 
and type its call as a high command. 


The typings of the methods in the Decrypt class must be included in the 
initial type environment since they are free in the Applet. Therefore, we first analyze 
| the Decrypt class and then merge the typings of this class with our initial type 
environment in order to analyze the Client Applet. But the analyzer fails on the 
Decrypt class and for good reason. In Java Card 2.0, user exceptions cause the 
control of the program to be transferred to the JCRE. Such an exception arises if 
the key is not set (key == 0) in our example. The exception KEY_NOT_SET reaches 


the JCRE where it can be observed at the interface (card reader). The presence of 
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the exception reveals whether key is zero, a violation of secure information flow. The 
secure flow analyzer requires the guard of the conditional, where key is checked, to 
be low. But key is high, so the analyzer produces an unsatisfiable constraint set with 


the inconsistent constraints 
(<= HIGH 8) (= 8 LOW) 


The results of the analyzer are given in Figure 10. The analyzer generates a constraint 


set and a typing for each field and method of the Decrypt class in Figure 9. 


Identifier : Decrypt .KEY_NOT_SET 
Type oe 

Constraint Set 

Identifier : Decrypt .buffer 

Type : 4 arr var 


Constraint Set 


Identifier : Decrypt 

Type : 5 proc() 
Constraint Set 

Identifier : Decrypt .decrypt 
Type : 5 


Constraint Set 


Identifier : getDecrypt 
Type : & func() 
Constraint Set 


Identifier : decrypt 
Type : 16 proc(7 arr) 
Constraint Set : (<= HIGH 8) (= 8 9)(= 8 LOW) (<= 2 10) (= LOW 10) 


(= LOW 15) (= 7 11) (<= 11 12) (<= LOW 11) 
(<= LOW 13) (= 7 13) (= 7 LOW) (<= LOW 14) 
(= LOW 14) (<= 15 7) (<= 16 8) 


Figure 10. Results of the Analysis 
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VI. CONCLUSION 


Protecting private information stored on smart cards is important to smart- 
card manufacturers who would like to provide some sort of guarantees about privacy 
to card issuers. The approach taken in this thesis is based on work by Volpano 
and Smith, who introduced a type system for privacy in a procedural programming 
language [Ref. 1]. Extensions of their type system are proposed to handle object 
creation, function methods, and first-class array references in an object-oriented pro- 
gramming language called Java Card. Java Card is gaining acceptance among major 
smart-card manufacturers as an open platform for smart card applications. The type 
system has been implemented as a Java Card program analyzer and demonstrated on 
a sample smart-card application. 

The type system approach to privacy depends heavily upon the correctness of 
the inital type environment. The analyzer uses the initial type environment to get 
the security levels of variables that are free in the source code. Setting up an initial 
environment can be quite hard since you need to know the behavior of methods in 
the programming library, especially their interactions with the underlying operating 
system and hardware. The Java Card 2.0 specification strives to insulate card appli- 
cations from low-level implementation details via a relatively abstract programming 
interface called the Application Programming Interface (API). This leaves some free- 
dom to implement the API differently among the manufacturers. But then one cannot 
say for sure that these different implementations will preserve the semantic assump- 
tions used in determining the initial type environment. One really does need details 
of an underlying implementation in order to get the environment correct. Often, | 
though, such details are unavailable. 

The type system approach also seems to be at odds with the ISO-7816 stan- 
dard. It specifies the APDU as the interface between a smart card and a card reader, 


or acceptance device. Since the APDU buffer can be observed by anybody who has 
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access to a card reader, it should be regarded as low. On the other hand, sometimes 
it is used to hold private information entered via the reader by the card holder. So is 
the APDU buffer high or low? In essence, it is simultaneously a high and low variable! 
A more secure architecture would split the buffer into a private input channel and 
a public output channel which are much easier to treat in the type system. Smart 
cards with private LCD displays and private keypads seem more appropriate. This 
view is consistent with work done in exploring how smart cards can be used securely 


in a hostile environment (Ref. 6]. 


A. FUTURE WORK 


The type system described in this thesis imposes some rather strong restric- 
tions on Java Card Applets. First, function method bodies must be pure (no updates 
of free variables are allowed unless the variables are high). This restriction is hard to 
remove without giving up Confinement. 

Second, object creation is restricted in that only one instance of a class can be 
created by an Applet. Further, the type system does not assign types to objects and 
object references are not typed as first-class references like arrays. The difficulty here 
is assigning a security level to an object when its fields may need different security 
levels. Taking the object’s type to be the least upper bound of these levels might 
be too coarse. Allowing more than one. instance of a class also means methods of 
the class must be typed polymorphically, which is more difficult to implement [Ref. 
1]. There is also a problem with introducing object creation as an expression in the 
language since it involves executing a constructor that may have side effects. But 
allowing more than one instance of a class may not be worth the effort. If you look at 
the Java Card 2.0 specification, you will notice that the JCRE owns one instance of 
each exception and programmers are advised to use these instances in order to save 
on resources. Owning only one instance of a class is actually common in Applets. So 


limiting Applets to one instance of a class doesn’t look like it will be a problem in 
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practice. 

Lastly, dynamic method dispatching is prohibited because the type system 
needs to know the secure flow typing of a method call at compile time. Dynamic 
dispatching has a major impact on the type system. More experience should tell 


whether dynamic dispatching is really needed. 
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; Dennis: Volpano; Code CS /VO sa desiveserteshscasteaesinetoree geod eu 


Computer Science Department 
Naval Postgraduate School 
Monterey, CA 93943-5100 


. Craig Rasmussen, Code MA/RA 
Mathematics Department 

Naval Postgraduate School 
Monterey, CA 93943-5100 


. Ismail Okan Akdemir........... 
Cumhuriyet Mahallesi 
1. Yesil Sokak No:55/3 
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45400 Turgutlu/MANISA/TURKEY 
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